Środowiskiem pracy projektanta procesu jest produkt docuRob®WorkFlow proces modeler pozwalający na konstrukcje graficznych modeli procesów zgodnych z wytycznymi standardu OMG BPMN v. 2.02. Zgodnie z przyjętą metodyką projektowania można wykorzystywać narzędzie w poszczególnych fazach cyklu życiowego projektu od pojęciowego modelu procesu do jego wykonywalnej definicji.

Wykonywalna definicja procesu jest udostępniana w repozytorium procesów utrzymywanego w ramach narzędzia zintegrowanego z platformą wykonawczą produktu docuRob®WorkFlow. W ramach repozytorium definicji procesów zapewniono możliwości wersjonowanie definicji oraz kontrolowane wprowadzanie ich do eksploatacji. Platforma pozwala na równoczesne przetwarzanie procesów inicjowanych na podstawie różnych wersji ich definicji.

W dalszych sekcjach rozdziału omawiamy poszczególne klasy obiektów modelu procesu (ang. flow object) wykorzystywanych do tworzenia kolejnych poziomów modelu procesu.

Opis procesu

Definicja procesu (ang. process definition) jest kompletną reprezentacją procesu umożliwiającą jego wykonanie przez system zarządzania procesami. Definicja procesu dotyczy różnorodnych aspektów procesu, w szczególności: przepływu sterowania, przepływu danych, przypisania wykonawców oraz wywołania aplikacji w ramach czynności.

Rysunek 1. Zakładki definicji procesu

Modyfikacja definicji procesu powoduje utworzenie nowej wersji definicji. W danym momencie może istnieć (i być wykonywanych) wiele wersji tego samego procesu, ale tylko jedna z nich jest najbardziej aktualna, dostępna i będzie wykonywana dla wszystkich nowo uruchamianych procesów. Definicja procesu może być też częścią innego, bardziej złożonego procesu. Zakładki ekranu definicji procesu prezentuje Rysunek 1.

Nazwa procesu stanowi unikalny identyfikator definicji procesu w ramach danej instalacji docuRob®WorkFlow przy czym kolejne wersje definicji są identyfikowanych liczbami całkowitymi począwszy od 1.

Priorytet wyznacza poziom preferencji dla wszystkich instancji procesów uruchamianych na poziomie tej definicji. Priorytet może być określony zarówno na poziomie procesu jak i na poziomie definicji czynności. Domyślną wartością wskaźnika jest liczba 100 a maksymalna jego wartość to 2147483647. Definicja procesu wywoływana jako podproces może dziedziczyć priorytet odpowiadającej jej czynności złożonej lub zachować własny.

Data dostępności informuje o dacie udostępnienia procesu i określa początek okresu jego wykorzystania, natomiast data ważności określa czas do którego nowe instancji procesu mogą być tworzone na podstawie tej definicji.

Właściciel instancji (ang. process owner) identyfikuje pracownika odpowiedzialną za jego utrzymanie i eksploatację oraz najczęściej za wszystkie jego aspekty związane ze wspieraną przez niego działalności biznesową. Pracownicy występujące w tej roli zwyczajowo otrzymują wszystkie standardowe komunikaty dotyczące przekroczenia ograniczeń. Właściciel procesu jest definiowany wyrażeniem BPQL. Jeżeli nie określimy właściciela procesu to system automatycznie przypisze taką rolę do użytkownika wykonującego pierwszą czynność typu Użytkownik.

Czynności

Rysunek 2. Okno definiowania metadanych czynności

Czynność (ang. activity) jest pracą, która określa pojedynczy krok w ramach procesu. Czynność może być atomowa, złożona lub sterująca. czynność atomowa jest definiowana jako zadanie, czynność złożona jako podproces a czynność sterująca jako bramka.

W ramach zakładek Wykonawca, Post-akcja oraz Pre-akcja występuje pomocnik wyrażeń BPQL, dostępny przez usługę Wstaw, obsługujący wybór odpowiednich elementów wyrażeń z udostępnionych słowników (patrz Rysunek 3).

Rysunek 3. Pomocnik wyrażeń BPQL

Kolejność przepływu pracy pomiędzy czynnościami jest zdefiniowana przez rodzaj i warunki wyboru odpowiedniego przejścia. Każda czynność może mieć czynności ją poprzedzające i czynności następujące bezpośrednio po niej.

Wybór ścieżki wykonania procesu jest oparty o definicje konfiguracji przepływów wchodzących i wychodzących z czynności lub bramek. Tworzenie instancji elementów grafu procesu polega na obsłudze znaczników (ang. token) przepływających między nimi lub w przypadku zdarzeń na generowaniu lub otrzymywanie wyzwalaczy zdarzeń (ang. trigger). Pojęcie znacznika zostało wprowadzone jako intuicyjna ilustracja mechanizmu przekazywania sterowania pomiędzy elementami grafu procesu.

Definiowanie w ramach metadanych czynności zależności logicznych pomiędzy wchodzącymi przepływami pozwala na przyjęcie pożądanej dyscypliny instancjacji danego elementu grafu procesu a w przypadku wychodzących przepływów na wybór dalszej ścieżki przepływu znaczników. Definicję złączenia i rozpływu sterowania przestawia Rysunek 4.

Złączenie sterowania wejściami wielu wchodzących przepływów, lub inaczej obsługa wielu znaczników wchodzących do czynności, zależy od wskazanego operatora powodując dla:

• operatora AND instancjację czynności po wejściu znaczników przez wszystkie wchodzące przepływy
• operatora OR instancjację czynności po wejściu znaczników przez wszystkie wchodzące przepływy spełniające zdefiniowane dla nich wyrażenie warunkowe
• operatora XOR instancjację czynności po otrzymania pierwszego znacznika przez jakikolwiek z wchodzących przepływów.

Rozpływ sterowania wyjściami wielu wychodzących przepływów, lub inaczej obsługa wielu znaczników wychodzących z czynności, zależy od wskazanego operatora powodując dla:

• operatora AND wysłanie znaczników przez wszystkie wychodzące przepływy
• operatora OR wysłanie znaczników przez wszystkie wychodzące przepływy spełniające zdefiniowane dla nich wyrażenie warunkowe
• operatora XOR wysłanie znaczników przez pierwszy wychodzący przepływ spełniający zdefiniowane dla niego wyrażenie warunkowe lub nie ograniczone żadnym warunkiem

Rysunek 4. Parametry złączenia i rozpływu sterowania

Alternatywną techniką sterowania wyborem ścieżki procesu są bramki, które, poza większą elastycznością wyboru ścieżki procesu, stanowią istotne elementy pojęciowego modelu procesu. Sterowanie przepływem wykorzystujące bramki opisano szczegółowo w dalszych częściach dokumentacji. Bramki ze względu na ich widoczność w grafie procesu/podprocesu są preferowaną techniką definiowania rozgałęzień przynajmniej na poziomie pojęciowego modelu procesu.

Niezależnie od typu i rodzaju czynności wprowadzono możliwość wykonania skryptu BPQL lub zewnętrznej Aplikacji zarówno przed jej wykonaniem (Pre-akcja) jak i po jej wykonaniu (Post-akcja). Interfejs dla wprowadzenia skryptu BPQL przedstawiają odpowiednio Rysunek 5 i Rysunek 6.

Rysunek 5. Definicja Pre-akcji czynności

Akcje pozwalają na:

• wykonywanie dodatkowych działań na parametrach wejściowych i wyjściowych procesu, zmiennych globalnych lub parametrach wywoływanej w czynności aplikacji (np. ustawianie statusu, dodawanie wartości do licznika pętli, itp.)

• wywoływanie dodatkowych aplikacji przed rozpoczęciem i przy zakończeniu czynności.

  Akcje są wykonywane:

• w momencie przypisania czynności do danego wykonawcy. Akcja ta jest nazywana preakcją.

• w momencie kończenia wykonywania czynności (nie dotyczy przerywania czynności). Akcja ta jest nazywana postakcją.

Akcja jest reprezentowana jako wyrażenie BPQL lub jako wołana aplikacja. W przypadku reguły BPQL, w odróżnieniu od przypisania wykonawcy czy warunku przejść, nie ma ograniczeń na wartość zwracaną przez regułę BPQL wykonywaną w akcji.

Akcje wykorzystuje się najczęściej do odpowiedniego przygotowania parametrów wejściowych i wyjściowych aplikacji wywoływanej w czynności. Innym zastosowaniem akcji jest wykorzystanie jej do ustawiania wartości wskaźników procesu wyrażonych poprzez zmienne globalne.

Aby zdefiniować Preakcję, należy:

• w panelu listy procesów kliknąć na dany proces,
• przejść w prawym panelu na zakładkę 'Model' procesu. Odnaleźć właściwą czynność i kliknąć dwukrotnie. Na ekranie pojawi się okno dialogowe właściwości czynności,
• kliknąć na węźle Pre akcja.
• Wybrać właściwy Typ akcji.
• Jeżeli wybranym typem jest BPQL – należy zdefiniować właściwa regułę BPQL. Jeżeli została wybrana aplikacja, to należy podać specyfikację jej wywołania tak jak przy definiowaniu aplikacji.

Dla skryptu Pre-Akcji wprowadzono dodatkowo możliwość wykonania go w całości lub częściowo przed instancjacją czynności oznaczając go jako blok @beforePreAction.

Kod zawarty w tym bloku w odróżnieniu od reszty Pre-akcji, zostanie wykonany już podczas tworzenia czynności. W sytuacji gdy zdefiniowanych jest n wykonawców danej czynności, blok @beforePreAction wykonany zostanie n razy podczas tworzenia czynności (tworzonych jest n instancji czynności), natomiast pozostała część pre-akcji wykona się raz, bezpośrednio przed wykonaniem czynności.

Postakcję definiuje się analogicznie wybierając węzeł Post akcja.

Rysunek 6. Definicja Post-akcji czynności

W przypadku złożonych procesów o dużej zmienności typów obsługiwanych przypadków użycia ważnym elementem projektu otoczenie procesu jest wyznaczenie odpowiednich zasobów ludzkich dla zadań typu Użytkownik. Jednym z elementów parametryzacji Analitycznego symulatora wykorzystywanego w tym celu jest określenie parametrów wydajnościowych każdej czynności.

Rysunek 7 prezentuje interfejs opisu takich parametrów wydajnościowych czynności jak liczba potencjalnych wykonawców i średni czas realizacji zadania. Opcjonalnie można również podać średni koszty wykonania zadania.

Opis algorytmu Analitycznego symulatora oraz przykład jego zastosowania w projektowaniu oraz zarządzaniu procesem jest dostępny w dalszej części dotyczącej monitorowania i analizy działania procesów.

Rysunek 7. Parametry analitycznego symulatora dla czynności

Zadanie

Zadanie jest niepodzielnym elementem modelu w odróżnieniu od podprocesu, który może zawierać dowolnie złożony model obejmujący wiele elementów. Typy zadań wraz z ich symbolami graficznymi oraz opisem działania prezentuje Tabela 1.

Symbol	Nazwa	Opis
	Komunikat	Zdanie automatyczne wysyła komunikat zawierający metadane oraz treść komunikatu poprzez wywołaną aplikację służącą do komunikacji (poczta elektroniczna, komunikator elektroniczny, SMS). Parametry umieszczone w kontenerze procesu są przekazywane Aplikacji komunikacyjnej zgodnie z wymaganiami przyjętymi dla zadania typu Usługa.
	Odbiór	Zadanie po otrzymaniu znacznika nasłuchuje na otrzymanie wyzwalacza rzuconego przez odpowiadające mu zadanie rzucające Komunikat. Obsługa komunikatu wymaga wywołania odpowiedniej aplikacji kompatybilnej z aplikacją wykorzystaną w zadaniu rzucającym. W przypadku bramki sterowanej zdarzeniem zadanie występuje jako jedno ze zdarzeń wskazujących przepływ wychodzący bramki.
	Użytkownik	Wykonawcą zadania jest uprawniony Użytkownik, który otrzymał informacje o nowym zadaniu na swojej liście zadań. Interfejs wraz z odpowiednimi usługami jest dostarczany przez aplikację wywoływaną przez silnik workflow. Silnik docuRob®WorkFlow standardowo obsługuję interface użytkownika poprzez zintegrowany moduł formularzy elektronicznych. Przydział zadania do jednego lub wielu użytkowników jest sterowany przez skrypt BPQL wykorzystujący takie cechy potencjalnych wykonawców jak uprawnienia, kompetencje oraz miejsce i funkcja w strukturze organizacyjnej czy rola w procesie biznesowym.
	Ręczna	Zadanie jest udostępniane przez listę zadań odpowiedniemu użytkownikowi lub użytkownikom lecz nie jest w żaden sposób zarządzanie przez silnik workflow za wyjątkiem oznaczenia śledzonych punktów czasowych w tym czasu rozpoczęcia i zakończenia
	Reguła biznesowa	Zadanie wykonywane automatycznie w oparciu o wyrażenia warunkowe BPQL. Wyrażenia warunkowe zawierają zmienne globalne procesu, zmienne lokalne skryptu oraz dane zewnętrznych baz danych i/lub plików XML. Wynikiem działania jest ustawienie wartości odpowiednich zmiennych globalnych procesu.
	Usługa	Zadanie jest wykonywane przez dostępną Usługę sieciową lub przez Aplikację wywołaną bezpośrednio przez silnik workflow. Wołane aplikacje są odpowiedzialne za obsługę interface użytkownika i mogą być implementowane w dowolnym języku programowania.
	Skrypt	Zadania jest wykonywane przez skrypt BPQL działający w oparciu o dane kontenera procesu, zmienne ontologii procesu, oraz o zewnętrzne źródła danych.

Tabela 1. Typy obiektu zadanie.

Przypisanie aplikacji (ang. application call specification**) definiuje sposób wywołania danej aplikacji w ramach** zadania**. Dotyczy to również określenia reguł mapowania parametrów wejściowych i wyjściowych** podprocesu**.**

Rysunek 8. Definicja parametrów Aplikacji obsługującej obiekt zadanie

Mapowanie parametrów Aplikacji (Tabela 2) określa jak:

• przypisać wartość parametrom wejściowym aplikacji wykonywanych w ramach czynności,
• przypisać zmienną globalną, do której zostaną przekazane rezultaty wykonania aplikacji czynności.

Do definiowania mapowań wykorzystywane są reguły BPQL. Atrybuty mapowań parametrów są opisane w Tabela 2.

Definicja Aplikacji jest wymagana dla takich typów zadań jak Użytkownik i Usługa oraz opcjonalne dla typu czynności Wysłania i Odbioru oraz Reguły biznesowej. W pierwszym przepadku istnieje możliwość wykorzystania zewnętrznego oprogramowania (poczta elektroniczna, bramka SMS, komunikator) a w drugim można korzystać poza regułami BPQL z zewnętrznego silnika regułowego jak na przykład Drools.

Nazwa atrybutu	Opis atrybutu
id	Identyfikator mapowania.
Nazwa	Nazwa atrybutu aplikacji, którego dotyczy mapowanie.
Wartość	Reguła języka BPQL reprezentująca mapowanie.

Tabela 2. Specyfikacja atrybutów mapowań parametrów Aplikacji

Rysunek 9. Formatka mapowania wartości parametru aplikacji

System docuRob®WorkFlow wspiera trzy protokoły wywołania:

• Java – aplikacja implementuje interfejs aplikacji zewnętrznej zdefiniowany w systemie docuRob®WorkFlow i jest implementowana jako klasa języka Java. Protokół ten działa tylko w trybie synchronicznym. Pole usługa specyfikuje pełną lokalizację klasy (pakiety i nazwa klasy). Ten protokół służy również do wywoływania konektora usług sieciowych REST (Representational State Transfer).
• URL – aplikacja jest wywoływana za pomocą adresu URL dostępnego poprzez protokół HTTP. Protokół ten charakteryzuje przede wszystkim wywołanie czynności manualnej i działa tylko w trybie synchronicznym. Pole Usługa specyfikuje konkretny adres wywołania.
• WebService – aplikacja jest usługą sieciową udostępniająca jedną lub więcej operacji. Specyfikacja aplikacji może być pobrana z serwera UDDI (Universal Description, Discovery and Integration lub bezpośrednio z pliku WSDL. Po odczytaniu specyfikacji danej usługi automatycznie wczytywana jest lista parametrów wejściowych i wyjściowych. Protokół ten charakteryzuje wywołanie czynności automatycznej i działa w trybie asynchronicznym. Pole Nazwa określa nazwę usługi a pole Usługa specyfikuje nazwę wywoływanej operacji w tej usłudze. Specyfikacja usługi może wykorzystywać protokół SOAP lub REST.
• Konektor usług sieciowych REST – umożliwia wykorzystanie usług sieciowych udostępnianych przez zewnętrzne aplikacje. Usługi REST stanowią powszechnie używane narzędzie wykorzystywane w procesach integracyjnych realizowanych w oparciu o oprogramowania narzędziowe docuRob®WorkFlow.

Standardowe zadanie Użytkownika

W ramach zadań Użytkownika możemy wykorzystywać dowolne aplikacje udostępniane zgodnie z protokołem języka Java obsługujące graficzny interfejs użytkownika. W ramach platformy docuRob® dostarczamy oprogramowania narzędziowe docuRob® Object Manager obsługujące repozytorium dokumentów wykorzystywanych w procesach pracy, które umożliwia projektowanie i implementację graficznego interfejsu użytkownika opartego o formularze elektroniczne docuRob® eForms.

Rysunek 10. Definicja standardowej aplikacji Użytkownika

Rysunek 10 pokazuje wywołanie usługi ObjectViewer obsługującej graficzny interfejs zadania. W tym przypadku w ramach graficznego interfejsu jest udostępniana sekcja o nazwie obszar2.

Parametrami wołanej usługi zarządzania interfejsem są:

• Identyfikator obiektu (ObjectId), którego wartość jest przekazywana przez zmienną kontenera $obj.
• Sposób wykorzystania interfejsu (mode) przyjmujący wartości edit, view, Parametr view udostępnia wybrane sekcje w trybie „do odczytu” pokazując wyłącznie ich treść bez dostępu do funkcji użytkowych.
• Parametr wyboru sekcji formularza (showFormSections) wskazuje nazwę prezentowanej sekcji formularza. Wartość parametru może być przekazywana również przez zmienną kontenera typu String
• Parametr (sections) wskazuje prezentowany zakres interfejsu i może przybierać wartości attributes, form, files.
• Parametr (editFormSections) pozwala na wskazanie prezentowanych sekcji formularza, które mogą być edytowane jeżeli parametr (mode) ma wartość edit.

Przykładem zastosowania graficznego interfejsu użytkownika opartego o usługę ObjectViewer jest proces zarządzający pracą grupową w którym zachodzi konieczność dynamicznego wyboru modelu prezentacje sekcji (obszarów) zdefiniowanych w formularzu przetwarzanego obiektu.

Rysunek 11 prezentuje graf procesu zarządzającego procedurą opracowania dokumentu realizowanej w ramach grupy roboczej zdefiniowanej w ontologii (patrz docuRob® Ontology Manager). Zadanie „Opracowanie” jest wykonywane wielokrotnie i ze względu na specyfikę obsługiwanej procedury w ramach kolejnych iteracji zachodzi konieczność dynamicznego dopasowania jego interfejsu graficznego.

Rysunek 12 prezentuje graf historii wykonania instancji procesu wskazujący przebieg jego iteracji, które obejmują czterokrotne wykonania zadania „Opracowanie” każdorazowo z innym graficznym interfejsem użytkownika. Różnice są widoczne zrzutach formularza udostępniającego inne sekcje w ramach kolejnych iteracji wykonania zadania „Opracowanie”. Parametry prezentacji formularza wprowadzane do zakładki Aplikacja definicji Czynności przedstawia Rysunek 13.

Rysunek 11. Model procesu pracy grupowej „Opracowanie dokumentu”

Rysunek 12. Graf historii wykonania procesu pracy grupowej „Opracowanie dokumentu”

Rysunek 13. Definicja aplikacji zadania „Opracowanie”

Rysunek 14 przedstawia widoki formularza w kolejności wykonania poszczególnych iteracji zadania „Opracowanie” uporządkowane chronologicznie od pierwszej do czwartej instancji zadania. We wszystkich przypadkach dopuszczalne jest edycja obszaru Autor formularza. Pozostałe sekcje są udostępniane wyłącznie do odczytu.

Wynikiem procesu było uzupełnienie dokumentacji przetwarzanego Obiegu systemu EZDRP dokumentami wytworzonymi w trakcie przebiegu procesu Pracy Grupowej zgodnie z jego modelem ( Rysunek 11). Listę dokumentów oznaczonych przedrostkiem „imp” zapisanych w repozytorium systemu EZDRP prezentuje Rysunek 15.

Rysunek 14. Kolejne modyfikacje interfejsu graficznego zadania „Opracowanie”

Rysunek 15. Dokumenty Obiegu systemu EZDRP

Pełny obraz formularza procesu w formacie pdf, który przedstawia Błąd! Nie można odnaleźć źródła odwołania., zwiera nazwiska wykonawców kolejno wykonujących zadania procesów. Ze względu na przyjętą procedurę w trakcie przebiegu procesu nie ujawniano danych wykonawców.

Rysunek 16. Pełny obraz formularza w formacie pdf.

IF ($step=1) THEN  {$viewOpracowanie:='Autor'; }
IF ( $step=2) THEN  $viewOpracowanie:='Autor,Recenzent';
IF( $step=3) THEN  $viewOpracowanie:='Autor,Redaktor';
IF ( $step=4) THEN  $viewOpracowanie:='Autor,Akceptacja';
$editSectionsOpracowanie:='Autor';

Powyżej przedstawiamy Wyrażenia BPQL wykonywane w ramach Pre-akcji zadania „Opracowanie”, które sterują prezentacją obszarów formularza w ramach poszczególnych jego iteracji. Wybór obszarów formularza oraz ich nazwy zostały opisane w trakcie projektowania interfejsu w edytorze formularza platformy docuRob®.

Konektor usług SOAP

Zestaw informacji definicji wywołania usługi SOAP przedstawiają odpowiednio Rysunek 17 do Rysunek 23.

Rysunek 17. . Przykładowa definicja parametrów Aplikacji dla wywołania usługi SOAP

W celu określenia lokalizacji WSDL’a należy wybrać przycisk oznaczony ikonką zielonego plusa

Rysunek 18. Fragment okna definicji parametrów Aplikacji dla protokołu Web Service

W wyświetlonym interfejsie należy podać adres URL usługi sieciowej czyli lokalizację pliku WSDL.

Rysunek 19. . Interfejs wskazania lokalizacji WSDL

Po zatwierdzeniu następuje odczytanie specyfikacji zawartej w WSDL. Następnie w polu Nazwa należy wybrać dostępną pozycję z nazwą serwisu.

Rysunek 20. Wskazanie serwisu w polu Nazwa

Po wskazaniu serwisu w polu Nazwa automatycznie wypełnione zostaną pola: Usługa, Endpoint oraz wczytywana zostanie lista parametrów wejściowych i wyjściowych w tabeli Parametry.

Rysunek 21. Przykładowa definicja parametrów Aplikacji po wskazaniu serwisu

W polu Usługa można wskazać jedną spośród dostępnych usług dla serwisu

Rysunek 22. Wybieranie usługi

Po każdym wybraniu usługi wczytywana jest lista parametrów wejściowych i wyjściowych. Należy wyspecyfikować parametry wejściowe i wyjściowe usługi poprzez uzupełnienie kolumny Wartość w tabeli Parametry.

Rysunek 23. Przykładowa definicja parametrów usługi

Konektor usług REST

Usługę sieciową REST można wywołać przy wykorzystaniu predefiniowanej klasy Java. Wywołujemy ją w protokole JAVA, specyfikując nazwę i usługę podając pełną nazwę klasy:

pl.rodan.ooworkflow.environment.activity.CallRestService

Przykład wywołania usługi REST systemu eDoręczenia pokazuje Rysunek 24.

Należy dodatkowo wyspecyfikować atrybuty wejściowe:

• method - do określenia metody wywołania ['GET', 'POST', 'PUT', 'DELETE']
  • URL - do określenia adresu wywołania wraz z parametrami
  • requestBody - do określenia zawartości wywołania, należy zachować format JSON
  • oraz Rodzaj atrybut wyjściowy:
  • responseBody - do wskazania parametru, w którym zostanie umieszczona odpowiedź wywołania usługi w formacie JSON.

Rysunek 24. Przykładowa definicja parametrów konektora dla wywołania usługi REST

Rysunek 25 i Rysunek 26 pokazują odpowiednio graf historii wykonania procesu zawierającego odwołanie (czynność nr 13) do usługi REST i stan zmiennych globalnych w kontenerze procesu.

Rysunek 25. Graf historii wykonania odwołania do usługi REST

Rysunek 26. Stan zmiennych globalnych procesu po wykonaniu usługi

Przykładem wykorzystania usługi konwersji formularza docuRob®eForms wykorzystywanej przez podproces „Form.xml 2 Form.pdf” w procesie pracy grupowej, którego definicję przedstawia Rysunek 11.

Rysunek 27. Definicja wywołania usługi REST w podprocesie konwersji

Przygotowanie parametrów usługi

Pre-akcja

$_om_url := 'http://om-dev.docurob.com:8084';
/*Pobranie skonwertowanego pliku xml.pdf */
$rest_method := 'GET';
$rest_url := $_om_url + '/api/internal/object/'+$in_ID_OBIEKTU+'/form-pdf';
$rest_headers := '';
$rest_requestBody := '';

Przypisanie wykonawcy zadania

Zaznaczenie opcji Jeden oznacza, że system pozwoli tylko jednemu z potencjalnych, to jest wybranych przez wyrażenie BPQL, wykonawców na wykonanie zadania jednocześnie, po podjęciu zadania z listy zadań przez jednego z wykonawców likwidując wpis zadania z list zadań pozostałych wybranych użytkowników. Wybranie opcji Wszyscy powoduje utworzenie czynności wielowątkowej wykonującej tyle instancji zadań ilu użytkowników zostało wybranych przez wyrażenie BPQL.

W procesie pracy grupowej, którego model prezentuje Rysunek 11, obowiązuje oczywista reguła wykluczające wystąpienie tej samej osoby w roli „autor” (czynność nr 5) i w roli „recenzent” (czynność nr 7) w ramach tej samej instancji procesu. Implementacja tej reguły jest oparta o wyrażenia i funkcje wbudowane BPQL realizujące działania na zbiorach wykonawców zadań „Opracowanie” i „Recenzja”.

Rysunek 28. Definicja Wykonawcy dla zadania.

Przypisanie wykonawców zadania „Opracowanie”

UserHasRoleInWorkgroup('autor','100419770') \ WM_Fun_ActivityOwner('7')

Przypisanie wykonawców zadania „Recenzja”

UserHasRoleInWorkgroup('recenzent','100419770') \ WM_Fun_ActivityOwner('5')

Podproces

Podproces nazywany również czynnością złożoną jest samodzielnym elementem dostępnym w ramach biblioteki definicji procesów, który może być wykorzystany zarówno jako element funkcjonalny obejmującego go procesu lub jako samodzielny proces najwyższego poziomu wywoływany przez zewnętrzny system informatyczny. Podproces występuje w grafie obejmującego go procesu jako symbol zadania oznaczony w dolnej linii opisu znakiem +

Klasycznym przykładem takiej architektury oprogramowania może być proces rozpoznawania treści dokumentu (ang. Optical Character Recognition (OCR)), który jest wykorzystywany do automatyzacji rozpoznawania różnych dokumentów, na przykład faktur lub aktów notarialnych, zarządzanych zazwyczaj różnymi procesami obiegu dokumentów. Definicja podprocesu obejmuje jego dane, to jest parametry wejściowe i wyjściowe oraz zmienne globalne i lokalne. Enkapsulacja definicji procesu/podprocesu powoduje pełną izolację ich Kontenerów danych.

Ze względu na usytuowanie definicji podprocesu w grafie obejmującego go procesu, który poprzez warunki przepływów tworzy kontekst jego instancjacji, może on zawierać tylko jedno zdarzenie startowe oznaczone jako „Początek”. Podprocesy mogą być zagnieżdżane na wielu poziomach. Współpraca zagnieżdżonych procesów jest możliwa dzięki wymianie parametrów.

Rysunek 29 prezentując pola definicji wywołania procesu udostępnionego w bibliotece dostępnych procesów narzędzia projektowania, który ma być udostępniony jako podproces w ramach definiowanego procesu wyższego poziomu. Powiązanie pomiędzy definicją integrowanego procesu a wołającym go procesem/podprocesem odbywa się przez nazwę biblioteczną tego pierwszego.

Jeżeli wołany proces ma zdefiniowane parametry wejściowe i/lub wyjściowe to automatycznie zostaną one umieszczone w polu parametrów w zakładce proces definicji wołającego procesu. Dla każdego z umieszczonych na liście parametrów należy dodać wyrażenie BPQL używającego zmiennych globalnych. Utworzony w ten sposób zostanie mechanizm przekazywania wartości parametrów pomiędzy procesem wyższego poziomu a wołanym przez niego podprocesem.

Rysunek 29. Wywołanie dostępnego procesu obsługującego dany podproces

Aby zdefiniować nowy parametr wejściowy lub wyjściowy procesu w narzędziu projektowania procesów, należy:

• przejść na dany proces znajdujący się w panelu listy definicji procesów
• przejść na węzeł Kontener, w prawym panelu zostanie wyświetlona lista aktualnie zdefiniowanych atrybutów kontenera procesu
• Wybrać pozycję menu Kontener->Dodaj
• Wprowadzić dane o parametrze, w tym:
  • Nazwa – podać unikalną nazwę. Zasadniczo jako nazwę podaje się ciąg znaków alfanumerycznych rozpoczynających się małą literą. Każdy nowy wyraz jest dołączany do istniejących i zaczyna się od dużej litery. W nazwie atrybutu nie zaleca się stosować polskich znaków diakrytycznych.
  • Rodzaj – dla parametru wejściowego należy wybrać wartość in. Dla parametru wyjściowego – wartość out. W przypadku gdy dany parametr wejściowy jest wykorzystany także jako parametr wyjściowy (rezultat), należy ustawić Rodzaj na in/out.
  • Tylko do odczytu – wskazuje, że dany parametr będzie wykorzystywany tylko do odczytywania danych a w momencie próby zapisu wystąpi błąd. W przypadku parametru wejściowego parametr ten jest automatycznie ustawiany na Tylko do odczytu. W przypadku parametru wyjściowego parametr ten powinien pozostać odznaczony.
  • Typ -typ atrybutu, należy wybrać właściwy typ z listy dostępnych typów.
  • Wielowartościowy – jeżeli parametr przyjmuje wiele wartości, to należy zaznaczyć to pole,
  • Obowiązkowy – jeżeli zawsze jest wymagana wartość atrybutu, to należy zaznaczyć to pole. Z praktycznego punktu widzenia opcja ta ma sens jedynie przy parametrach wejściowych bo najczęściej wartość parametru wyjściowego nie jest znana przy rozpoczęciu procesu.

Podproces sterowany zdarzeniem

Podprocesy sterowane zdarzeniem nie są powiązane ze strukturą przepływów obejmującego je procesu. Oznacza to, że taki podproces stanowi osobny graf umieszczony w ramach modelu obejmującego go procesu/podprocesu. Graf podprocesu sterowanego zdarzeniem jest otoczony nazwaną ramką z wykropkowanej linii i nie może być źródłem and celem żadnego Przepływu. W ramach modelu takiego podprocesu mogą wystąpić wszystkie obiekty przepływu przewidziane w BPMN 2.02 natomiast nie może on mieć zdarzeń krawędziowych.

Podproces sterowany zdarzeniem może zawierać tylko jedno początkowe zdarzenie przechwytujące, które nasłuchuje na odpowiadający mu zdarzenie rzucające od momentu instancjacji otaczającego procesu.

Zależnie od użytego w modelu symbolu zdarzenia mogą przerywać lub nie wykonanie instancji procesu/podprocesu otaczającego inicjowany przez nią podproces. Instancjacja podprocesu może mieć miejsce tylko gdy otaczający go proces/podproces jest aktywny przy czym może ona wystąpić wiele razy powodując utworzenie wielu współbieżnych instancji.

Instancja podprocesu sterowanego zdarzeniem jest w przypadku przechwytujących zdarzeń nieprzerywających tworzona dla każdego z równolegle zachodzących zdarzeń. Ze względu na ich umiejscowienie wewnątrz obszaru wywołującego je procesu/podprocesu podprocesy sterowane zdarzeniem mają dostęp do kontekstu obejmującego je procesu/podprocesu. Wykonanie obejmującego procesu/podprocesu odbywa się współbieżnie do uruchomionych instancji podprocesów sterowanych zadaniami.

Początkowe zdarzenia przerywające zawsze powodują przetwarzanie tylko jednej instancji podprocesu sterowanego zdarzeniem. Kontekst obejmującego przerywanego procesu/podprocesu jest dostępny dla oprogramowania obsługującego zdarzenie (ang. Event handler) w fazie zakańczania aby umożliwić dokończenie obsługi.

Podproces sterowany zdarzeniem może opcjonalnie powtórzyć (ang. re-trigger) zdarzenie, które go uruchomiło aby kontynuować jego przetwarzania na zewnątrz otaczającego go procesu/podprocesu poprzez jego odpowiednie zdarzenie krawędziowe.

Bramki

Czynność sterująca (ang. control activity, routing activity) jest elementem definicji przepływu sterowania wykorzystywanego do wykonania czynności równolegle, alternatywnie bądź opcjonalnie. Modelując proces mamy do dyspozycji dwie grupy bramek; a mianowicie bramki rozpływu generujące jeden lub więcej znaczników i sterujące ich dalszym przepływem i bramki łączenia otrzymujące jeden lub więcej znaczników i generujące jeden znacznik.

Bramki rozpływu

Symbol	Nazwa	Opis
	Bramka sterowana zdarzeniami	Konfiguracja bramki, w odróżnienia od pozostałych typów, zależy nie od wartości zdefiniowanych w niej warunków rozpływu lecz od konfiguracji zdarzeń umieszczonych na docelowych końcach jej przepływów wychodzących..
	Bramka rozpływu AND (AND Split)	Bramka tworzy wiele równoległych ścieżek generując znaczniki zgodnie z liczbą jej przepływów wychodzących bez sprawdzania jakichkolwiek wyrażeń warunkowych.
	Bramka rozpływu XOR (XOR Split)	Bramka tworzy jedną z alternatywnych ścieżek w ramach konfiguracji jej przepływów wychodzących. Wybrany przepływ wychodzący musi spełniać przypisane do niego wyrażanie warunkowe. Jeżeli żadne z jej przepływów wychodzących nie spełnia powyższego wymagania to znacznik jest przesyłany domniemanym przepływem wychodzącym jeżeli taki został uwzględniony w konfiguracji Bramki.
	Bramka rozpływu OR (OR Split)	Bramka tworzy wiele z alternatywnych ścieżek w ramach konfiguracji jej przepływów wychodzących. Wybrany przepływ wychodzący musi spełniać przypisane do niego wyrażanie warunkowe. Jeżeli żadne z jej przepływów wychodzących nie spełnia powyższego wymagania to znacznik jest przesyłany domniemanym przepływem wychodzącym jeżeli taki został utworzony.
	Złożona bramka rozpływu (Complex Split)	Bramka generuje przynajmniej jeden znacznik dla wybranego przepływu wychodzącego bramki a co najwyżej po jednym znaczniku dla każdego przepływu wychodzącego. Zarówno wybór właściwych przepływów wychodzących jak i generowanie znaczników wykonuje wyrażenie BPQL utworzone przez projektanta procesu.

Tabela 3. Typy operatorów rozpływu

Bramka służy do rozdzielenia sterowania. W terminach znaczników, Bramka konsumuje jeden znacznik a generuje jeden lub więcej znaczników w zależności od typu operatora. Reprezentacja graficzną operatora jest romb pogrubiony z lewej strony. Opis działania Bramek rozpływu zawiera Tabela 3.

Bramki łączenia

Bramka łączenia służy do złączenia sterowania. W terminach znaczników, operator ten konsumuje jeden lub więcej znaczników, w zależności od typu operatora a generuje jeden znacznik. Są trzy typy Bramek: ANDJoin, ORJoin i XORJoin. Reprezentacja graficzną operatora jest romb pogrubiony z prawej strony. Opis działania bramek łączenia opisuje Tabela 4.

Symbol	Nazwa	Opis
	Bramka łączenia AND (AND Join)	Znaczniki przybywające przez przepływy wchodzące do równoległej bramki łączenia (AND) są zamieniane na jeden znacznik wysyłany jej przepływem wychodzącym dopiero po otrzymania ich wszystkich.
	Bramka łączenia XOR (XOR Join)	Znaczniki spełniające warunki przejścia przybywające przez przepływy wchodzące do ekskluzywnej bramki łączenia (XOR) są zamieniane na jeden znacznik wysyłany jej przepływem wychodzącym po otrzymaniu przynajmniej jednego z wchodzących znaczników.
	Bramka łączenia OR (OR Join)	Znaczniki spełniające warunki przejścia przybywające przez przepływy wchodzące do bramki łączenia (OR) są zamieniane na jeden znacznik wysyłany jej przepływem wychodzącym po otrzymaniu wszystkich aktywnych znaczników wygenerowanych przez poprzedzającą bramkę rozpływu

Tabela 4. Typy operatorów łączenia

Przepływy

Przepływ (ang. flow) jest łącznikiem pomiędzy dwoma czynnościami wskazując kolejność ich wykonywania. Przejście może posiadać warunek. Wyrażenie warunkowe jest definiowane jako reguła BPQL. Aktywność przepływu jest symbolicznie interpretowana jako przesłanie znacznika (ang. token) pomiędzy czynnościami. Warunkiem aktywności przepływu, który ma wyrażenia warunkowe jest zwracanie prze nie wartości „prawda” (ang. true). Typy Przepływów prezentuje Tabela 5.

Symbol	Nazwa	Opis
	Przepływ (ang. Sequence flow)	Przepływ może ale nie musi zawierać wyrażenia warunkowego sterującego przekazaniem znacznika pomiędzy czynnościami
	Przepływ wychodzący z zadania z warunkiem	Przepływ wychodzący z zadania jest oznaczany rombem jeżeli zawiera definicję warunku.
	Domyślny przepływ (ang. default flow)	Domniemany przepływ przekazuje znacznik pomiędzy czynnościami jeżeli wyrażenia warunkowe wszystkich Przejść wychodzących zadania lub bramki mają wartość „fałsz” (ang. false).

Tabela 5. Typy przepływów

Panel definiowania metadanych Przepływu (Rysunek 30) obejmuje wszystkie elementy konieczne do jego wykonania. Źródłowa i docelowa czynność są identyfikowane opcjonalnie nazwą i automatycznie numerem czynności w grafie procesu/podprocesu.

Wyrażenie warunkowe sterujące symbolicznie przekazaniem znacznika jest tworzone w BPQL i jest wspomagane edytorem wyrażeń języka zgodnie z ogólnymi zasadami przyjętymi w systemie. Warunek jest ignorowany jeżeli przepływ został oznaczony polem Domyślny.

Przepływ domyślny oznaczony odpowiednim polem wyboru jest wykonywany w przypadku gdy wszystkie inne przejścia nie mogą zostać uruchomione ze względu na przyjęte w nich wyrażenia warunkowe.

Warunki przejść są wyrażeniami logicznymi określającymi, czy dane przejście zostanie wykonane czy nie. Dany warunek jest reprezentowany przez regułę BPQL i może zawierać dowolne elementy języka, które ostatecznie wartościują się do typu Boolean. W praktyce warunek przepływu sterowania jest definiowany w oparciu o zmienne globalne procesu oraz funkcje BPQL, które udostępniają dane obiektów i formularzy przetwarzanych w ramach procesu.

Aby zdefiniować warunek, należy będąc na zakładce Model procesu zaznaczyć właściwe przejście i kliknąć dwukrotnie lewym klawiszem myszki. Na ekranie pojawia się okno dialogowe do wprowadzania danych o przejściu. Dostarcza ono następującej informacji:

• Od czynności – numer i nazwa czynności początkowej, od której jest zdefiniowane przejście. Wartość tylko do odczytu.
• Do czynności - numer i nazwa czynności końcowej, do której jest zdefiniowane przejście. Wartość tylko do odczytu.
• Nazwa – nazwa przejścia. Nazwa ta pojawia się w zakładce Model procesu.
• Opis – dodatkowa informacja o przejściu wypełniana w celach dokumentacyjnych.
• Warunek – wyrażenie BPQL.

Przy definiowaniu warunku przejścia możliwe jest wstawianie operatorów logicznych: AND, OR, NOT przy pomocy przycisków znajdujących się lewej dolnej części okna. W celu wybrania zmiennej globalnej lub funkcji wbudowanej BPQL, należy kliknąć na przycisk „Wstaw”. Na ekranie pojawia się standardowe okno wprowadzania informacji o strukturze organizacyjnej, funkcjach wbudowanych i zmiennych globalnych. W zakładce Struktura org. można wybrać cztery kategorie danych:

• Funkcja – na ekranie pojawia się lista funkcji BPQL, które można wykorzystać do zdefiniowania warunku. Wybór funkcji następuje po dwukrotnym kliknięciu na jej nazwę lub zaznaczeniu funkcji i kliknięciu na klawisz Wybierz
• Stanowisko – podaje listę stanowisk zdefiniowanych w systemie. Lista ta może się różnic w zależności od słowników danego klienta.
• Grupa – umożliwia wybranie grupy funkcyjnej lub komórki organizacyjnej zdefiniowanej w systemie docuRob®Ontology Manager lub zsynchronizowanej z właściwym systemem zarządzania pracownikami.
• Pracownik- lista pracowników zatrudnionych w danej grupie lub komórce organizacyjnej wybranej z rozwijanej listy grup i komórek.

Wybór zmiennej globalnej wykonuje się na drugiej zakładce. Po jej wybraniu wyświetlana jest lista dostępnych atrybutów wraz z informacją o typie i rodzaju zmiennej. Podwójne kliknięcie na daną zmienną powoduje jej wybranie.

Rysunek 30. Metadane obiektu Przepływ

Inne symbole graficzne

Wykorzystanie innych symboli graficznych w ramach grafu procesu omawia Tabela 6.

Symbol	Nazwa	Opis
	Rola (ang. Swimlane)	Intencją specyfikacji BPMN 2.02 jest wykorzystanie obszaru Rola do grupowania zadań wykonywanych przez Użytkowników procesu występujących w danej roli. Na przykład rola Technolog. Taka metoda modelowania grafu procesu w poważnym stopniu utrudnia zachowanie czytelności modelu. Dlatego wprowadziliśmy alternatywne oznaczanie zadań w ramach Roli poprzez odpowiednie przypisywanie kolorów wypełnień ich symboli.
	Obiekt danych (ang. data object)	Wprowadzenie Obiektów danych oraz ich powiązań z zadaniami ma znaczenie dla przekazania informacji projektowych na poziomie pojęciowego modelu procesu tworzonego w fazie analizy wymagań. Ze względu na obsługę danych w oparciu kontener danych procesu/podprocesu symbole Obiektów danych oraz ich powiązań nie są interpretowane na poziomie wykonania procesu.
	Powiązanie (ang. Association)	Symbol Powiązania jest wykorzystywany jako oznaczenia związku pomiędzy krawędziowym zdarzeniem typu „Kompensacja” a czynnością kompensującą”.
	Ramka (ang. Frame)	Ramka oznacza zakres grafu podprocesu sterowanego zdarzeniem, którego model umieszczono razem z otaczającym go procesem/podprocesem.

Tabela 6. Inne symbole graficzne

Rodzaje czynności

W ramach definicji czynności możemy wyznaczyć ich rodzaj (ang. kind) wstawiając w dolnej linii graficznego symbolu czynności odpowiednie wskaźniki rodzaju czynności. Reguły ich współwystępowania w definicji czynności oraz znaczenie określają odpowiednio Tabela 7 i Tabela 8.

znacznik	Współwystępujące znaczniki
	Pętla	Pętla sekwencyjna	Pętla równoległa	adHoc	Kompensacja
Pętla Pojedyncza	X				T
Pętla Sekwencyjna		X			T
Pętla Równoległa			X		T
adHoc	T	T	T	X	T
Kompensacja	T	T	T	T	X

Tabela 7. Reguły użycia Wskaźników rodzaju czynności w metadanych

Grupy metadanych czynności, wspólne dla potomnych obiektów modelu i udostępniane w ramach hierarchii dziedziczenia, są prezentowane w tej sekcji. Pozostałe elementy metadanych są omawiane odpowiednio w sekcjach dotyczących zadania i podprocesu.

Informacje ogólne zawierają takie elementy jak nazwa czynności i numer czynności w ramach tworzonego modelu procesu. Dla czynności Użytkownik, Usługa, Skrypt i Podproces są definiowane wskaźniki rodzaju czynności które zawiera Tabela 8. Pole Opis pozwala na tworzenie dokumentacji czynności, która opcjonalnie może być udostępniana również użytkownikom instancji procesu wykonujących to zadanie.

W przypadku rodzaju pętla pojedyncza dodano osobne pole wyboru „Pętla” wraz z polem pozwalającym w wprowadzenie wyrażenia BPQL wyznaczającego warunek zakończenie pętli. Instancje Zadania są wykonywane w pętli w ramach instancji czynności dla tego samego wykonawcy do momentu zmiany wartości zmiennej kontrolującej zakończenie pętli na logiczną wartość ‘true’. Zmienna logiczna jest inicjowana wartością ‘false’ w trakcie instancjacji czynności. Warunek kończenia jest definiowany jako wyrażenie warunkowe BPQL.

Wskaźnik	Nazwa
	Pętla Pojedyncza
	Pętla Sekwencyjna
	Pętla Równoległa
	adHoc
	Kompensacja

Tabela 8. Wskaźniki wyznaczające rodzaj czynności

Rysunek 31. Definiowanie pętli wykonania czynności

Pętla pojedyncza

Pętla pojedyncza wykonywana przez iteracyjnie tworzone zadania inicjowane dla tego samego wykonawcy. Zarządzanie wykonawcami wyznaczonymi przez wyrażenie BPQL jest realizowane analogicznie do przypadku pojedynczego zadania.

Rysunek 32. Definicja parametrów pętli pojedynczej

Rysunek 33. Graf historii wykonania procesu Activity Pętla Pojedyncza

Dla kontroli liczby iteracji można wykorzystać funkcję BPQL LoopCounter(), która zwraca aktualny licznik pętli. Funkcja jest możliwa do wykorzystania jedynie w warunkach pętli (w innych przypadkach może zwracać stan nieokreślony lub generować błąd).

Rysunek 34. Lista czynności wykonanych w instancji procesu z pętlą pojedynczą

Przykład wykonania pętli obejmującej trzy iteracje dla tego samego wykonawcy, (w tym przypadku występuje użytkownik Abacki Kierownik komórki C), przedstawia graf historii wykonania (Rysunek 33) a szczegółowe informacje dotyczące historii wykonania poszczególnych instancji zadań procesu przedstawia Rysunek 34.

Czynność pętla pojedyncza jest kończona i przekazuje znacznik odpowiednim przepływem wychodzącym po zakończeniu wszystkich iteracji.

Pętla sekwencyjna

Deklaracja pętli sekwencyjnej (ang*.* Multi-instance loop) powoduje kolejne wykonanie przetwarzanych instancji zadań. Każda instancja jest wykonywana kolejno dla każdego wykonawcy znajdującego się w zbiorze wynikowym wyrażenia BPQL wyznaczającego listę wykonawców. Graficzną historię wykonania instancji procesu obejmującego czynność pętla sekwencyjna oraz historię wykonania zadań tego procesu przedstawiają odpowiednio Rysunek 35 i Rysunek 36.

Rysunek 35. Graf historii wykonania procesu Activity Pętla Sekwencyjna

Rysunek 36. Lista zadań wykonanych w instancji procesu z Pętlą sekwencyjną

Listy wykonawców czynności pętla sekwencyjna i pętla równoległa w omawianych przykładach obejmujących je procesów wyznacza wyrażenie BPQL (Rysunek 37).

Rysunek 37. Definicja wykonawców zadania (BPQL) dla pętli sekwencyjnej i pętli równoległej

Czynność pętla sekwencyjna jest kończona i przekazuje znacznik odpowiednim przepływem wychodzącym po zakończeniu wszystkich zawartych w niej instancji zadań realizowanych przez poszczególnych wykonawców.

Pętla równoległa

Graficzną historię wykonania instancji procesu obejmującego czynność pętla sekwencyjna oraz historię wykonania zadań tego procesu przedstawiają odpowiednio Rysunek 38 i Rysunek 39

Rysunek 38. Graf historii wykonania procesu Activity Pętla Równoległa

Deklaracja pętli równoległej (ang. parallel Multi- instance) powoduje współbieżne wykonanie przetwarzanych instancji zadań. Czynnośc jest wykonywana dla każdego wykonawcy znajdującego się w zbiorze wynikowym wyrażenia BPQL wyznaczającego listę wykonawców.

Rysunek 39. Lista czynności wykonanych w instancji procesu z pętlą równoległą

Czynność pętla równoległa jest kończona i przekazuje znacznik odpowiednim przepływem wychodzącym po zakończeniu wszystkich zawartych w niej instancji zadań realizowanych przez poszczególnych wykonawców.

Czynność wielowątkowa

Czynności wielowątkowe (ang. multi-threading) pozwalają na modelowanie i wykonanie współbieżnych zadań w ramach tej samej czynności. W odróżnieniu od pętli równoległej, która generuje jeden znacznik wychodzący po zakończeniu wszystkich współbieżnych zadań, zakończenie poszczególnych wątków powoduje wygenerowanie znaczników tym samym inicjując kolejne ścieżki instancji procesu.

Rysunek 40 prezentuje graficzną historię procesu w którym czynność A wykonuje 3 wątki a następnie przesyła znaczniki zgodnie rolami wykonawców do czynności AA lub BB. Odpowiadająca mu lista historia wykonania zadań instancji procesu jest pokazana na Rysunek 41.

Rysunek 40. Graf historii procesu zawierające Czynność Wielowątkową (A)

Każdy z wykonywanych wątków jest niezależną instancją zadania wykonywanego przez jednego wykonawcę z pośród wybranych na podstawie wyrażenia BPQL. W odróżnieniu od czynności jednowątkowej w tym przypadku zadania są przydzielane wszystkim użytkownikom uczestniczącym w zbiorze wykonawców. Po zakończeniu każdego zadania (wątku) znacznik jest przekazywany do następnej czynności zgodnie z przyjętym schematem rozpływu.

Rysunek 41. Lista czynności wykonanych w instancji procesu z czynnością wielowątkową

Wybór rodzaju czynności polega na ustawienia pola wyboru (Jeden/Wszyscy) umieszczonego w lewym dolnym rogu ekranu Wykonawca. Można również wyliczyć liczbę wykonawców czynności wielowątkowej używając w ramach definicji *Pre-*akcji dyrektywę @beforePreAction pozwalającą na wykonanie dowolnego bloku instrukcji BPQL. Dyrektywa jest wykonywana przed rozpoczęciem każdego z zadań przez wyznaczonych wykonawców.

Rysunek 42. Ustawienia parametrów czynności wielowątkowej

Czynność Kompensacja

Wskaźnik kompensacja oznacza czynność, która odwraca skutki powiązanych z nią czynności, to jest zadania lub podprocesu. Powiązanie kompensowanej czynności jest realizowana poprzez odpowiednie zdarzenie przechwytujące „kompensacja” powiązane przez związek (ang. Association) z czynnością kompensującą. Warunkiem wykonania kompensacji jest pozytywne zakończenie odwracanej czynności. Jeżeli taki warunek nie zachodzi dla wskazanej czynności to kompensacja nie jest wykonywana.

Wykonanie powiązanych czynności kompensowana i kompensująca jest sterowane odpowiednimi zdarzeniami rzucającymi i przechwytującymi i w związku z tym zostało szczegółowo przedstawione artykule Zdarzenia.

Czynność adHoc

Wskaźnik może występować w przypadku definicji czynności i oznacza, że wszystkie takie czynności występujące w ramach procesu/podprocesu. W przypadku zadań typu Użytkownik instancje zadania mogą być wielokrotnie tworzone i wykonywane przez wszystkich użytkowników wyznaczonych dla nich wyrażeniem BPQL. Czynności adHoc nie mogą mieć przepływów wchodzących i wychodzących.

Zadania adHoc są wykonywane zgodnie z następującymi regułami:

1. Instancje zadań adHoc są aktywizowane razem z zawierającą je instancją procesu/podprocesu. Przetwarzanie instancji zadania adHoc jest kończone poprzez wyjście z czynności przez usługę Zamknij lub spełnienie się jego warunku zakończenia zadania. Instancja zadania może również zostać zakończona przez przerywające zdarzenie krawędziowe.
2. Instancjacja zadania AdHoc następuje w momencie instancjacji otaczającego go procesu/podprocesu. Potencjalni wykonawcy zadania wyznaczani przez wyrażanie BPQL przy czym podjęcie zadania przez jednego z wykonawców nie powoduje usunięcia zadań u pozostałych wybranych wykonawców.
3. Użycie usługi Wróć powoduje, że instancja zadania jest dostępna na liście zadań bieżących danego wykonawcy. Powrót do wykonywania zadania następuje przy użyciu usługi Otwórz.

Przykład alternatywnych metod sterowania przepływami

Przedstawiony przykład jest celowo neutralny z punku widzenia aplikacyjnego i wszystkie zawarte w nim czynności są oznaczone dużymi literami alfabetu. Celem przykładu jest ilustracja alternatywnych metod modelowania procesu, to jest sterowania poprzez definicję rozpływu i łączenia sterowania przez operatory logiczne udostępniane w zakładce „Przepływ” panelu definicji czynności (Rysunek 43) lub poprzez definicję bramek rozpływu i łączenia (Rysunek 44).

Rysunek 43. Definicja procesu z przepływami definiowanymi w metadanych czynności

Przedstawione modele alternatywnych procesów są wygenerowane przez narzędzie projektowania procesów platformy docuRob®WorkFlow. Celowo pominięto możliwość oznaczanie ról wykonawców w zadaniach typu „Użytkownik”. Rysunek 45 do Rysunek 48 ilustrują historię wykonania czterech różnych przebiegów procesów

Rysunek 44. Definicja procesu z przepływami przez Bramki

Wykonane przebiegi czterech par instancji procesów powołanych odpowiednio na podstawie alternatywnych modeli różnią się między sobą wartościami logicznymi (typ Boolean) zmiennych globalnych sterujących przepływami w ramach obu instancji. Różnice w ustawieniu wartości zmiennych logicznych w wariantach wykonania modeli 1-4 pokazuje Tabela 9. Dla kolejnych wariantów przebiegów pokazano jedynie wiersze różniące w się w stosunku do wariantu przebiegu 1.

Przebieg 1 (Rysunek 45) został wykonany po wprowadzeniu zmiennych globalnych o wartościach „true” jako parametrów wejściowych powoływanych instancji. Obie oczekiwane równoległe ścieżki instancji definicji (bramka AND) zostały wykonane.

Różnica pomiędzy wariantami 1 i 2 wykonania par procesów polega na przypisaniu wartości false zmiennej logicznej $zn11 sterującą przepływem pomiędzy czynnościami A i B (Rysunek 43) lub w przypadku modelu opartego o bramki pomiędzy bramką Split OR a czynnością A (Rysunek 44). Zablokowanie tego przejścia spowodowała wykonania tylko jednej ścieżki procesu w wariancie przebiegu 2.

Przebieg	Czynność	In	Out	zn11	zn12	zn31	zn32	zn21	zn22	zn23
1	Start	XOR	AND	T	T	T	T	T	T	T
	A	OR	OR	T	T	T	T	T	T	T
	C	XOR	OR	T	T	T	T	T	T	T
	B	XOR	OR	T	T	T	T	T	T	T
	D	XOR	OR	T	T	T	T	T	T	T
	E	XOR	OR	T	T	T	T	T	T	T
	F	XOR	OR	T	T	T	T	T	T	T
2	A	OR	OR	F	T	T	T	T	T	T
3	A	OR	OR	T	F	T	T	T	T	T
	C	XOR	OR	T	T	T	F	T	T	T
4	E	XOR	OR	T	T	T	T	T	F	T

Tabela 9. Konfiguracje warunków przepływów w przebiegach 1-4.

Wariant przebiegu 3 przy ustawieniu zmiennych logicznych $zn12 i $zn32 na wartość false spowodowała zablokowanie rozpływu AND w obu modelach i odpowiednio zakończenie obu równoległych ścieżek instancji procesów po wykonaniu instancji czynności (zadań) A i C.

Wariant przebiegu 4 przy ustawieniu wartości zmiennej logicznej $zn22 na false pominie wykonanie czynności E.

Celem przykładu jest między innymi pokazanie ekwiwalencji funkcjonalnej instancji procesów opartych o alternatywne definicje modeli polegającej na uzyskaniu takich samych ścieżek wykonania zadań.

Wybór grafu opartego o czynności sterujące (bramki) jest semantycznie bogatszą alternatywą i wydaje się bardziej przyjazny dla użytkowników odpowiedzialnych za automatyzację procedur działalności w oparciu o architekturę procesową (przedstawiciele biznesu).

W przypadku zastosowania wewnętrznej definicji przepływów możemy oczekiwać zwiększonej wydajności przetwarzania instancji procesów (mniejszego obciążenia konfiguracji serwerowej) ze względu na uniknięcie obciążenia wynikającego z uruchamianiu większej liczby instancji czynności sterujących. Takie podejście jest niewątpliwie lepsze w przypadku procesów zawierających większość czynności automatycznych.

---

---

Rysunek 45. Przebieg 1

---

---

Rysunek 46. Przebieg 2

W ramach instancji procesów drugiego przebiegu wykonanego po przyjęciu warunku $zn11*=false* została wykonana ścieżka <Start, C, B, D, E, F>. Druga równoległa ścieżka została dla obu instancji przerwana na etapie przepływu wyjściowego zadania A. Łatwo zauważyć, że przerwania równoległej ścieżki procesu po wykonaniu instancji czynności A spowoduje jednokrotne wykonanie zadań <B, D, E, F>.

---

---

Rysunek 47. Przebieg 3

W trzecim przebiegu przyjęto wartości false dla zmiennych logicznych $zn12 i $zn32. Taka konfiguracja warunków przepływu spowodowała przerwania obu ścieżek po wykonaniu zadań A i C. W przypadku modelowania warunku wyjściowego zadania A wykorzystano przepływ domniemany.

---

---

---

Rysunek 48. Przebieg 4

W czwartym przebiegu przyjęto wartość zmiennej logicznej zn22=true co spowodowało niezgodność z warunkiem wejścia do zadania E. W instancjach obu modeli nie wykonana tej czynności.